A conventional store and forward switch for a packet switching system (i.e., Ethernet) can only deal with a finite amount of packets over a given time. Since one incoming packet can result in multiple outgoing packets, an overrun case can arise where a packet should be sent out on a selected port but there is no room to queue that packet on the output portion of the selected port. To avoid such an overrun, flow control is implemented. Flow control attempts to reduce the amount of incoming traffic to the output portion of the selected port when the resources in the switch or selected output port become depleted. Flow control is usually implemented on a per-output basis. If one or more input ports has sent a large amount of traffic to the selected output port that has become increasingly full, flow control on the input ports reduces the incoming traffic to the selected output port. Flow control should be minimized on input and output ports that are not resource limited. Flow control should attempt to target only the traffic flow that is likely to cause an overrun.
Conventional flow control approaches do not provide an efficient way to target flow control on only the most suitable port(s). Conventional flow control needs CPU interaction, large counters, and/or other logic.
One conventional approach is to implement flow control on the port from which the next incoming packet is received. The port that sent the particular incoming packet is not necessarily the port that has recently sent a large amount of traffic to the selected output port and, hence, may not be the best port to implement the flow control. Such an approach will implement flow control on all ports still sending traffic to the selected output port. Eventually the best port(s) will be flow controlled, but at the expense of other ports that may be unnecessarily flow controlled. Such unnecessary flow control is undesirable in many situations. Unnecessary flow control of all ports can result in a very inefficient data traffic flow.
A second conventional approach uses counters to keep a record (i) of how many packets have been received and (ii) from which port the packets originated. In some cases each counter can be reset during a read, so only the number of packets received since the last time the port was read needs to be, stored. The CPU can then read each counter in turn and determine which port had sent the most traffic since the last read. The second conventional approach needs either large counters, frequent CPU intervention, or both. In particular, a counter is needed for each possible input and another counter for every output. Each counter is likely to be large (i.e., a 24 port switch will need 23×24=552 counters of this size).
Since counting is generally done over a large time frame, conventional solutions do not necessarily give a good indication on which port most recently sent the most packets to a selected output port. This is a serious disadvantage. Also, conventional solutions are not always accurate since the time between each counter read cannot be fully controlled (i.e., due to interrupts) The count that is read for each port cannot be guaranteed to have been generated over the same time span as the time between each counter read.
It would be desirable to implement a flow control scheme that has the ability to react quickly and implement flow control on an input that has a short burst of traffic without needing CPU interaction, large counters, and/or other logic.